Read, Write, Talk, Sing, Play: What Early Literacy Can Teach Us About Software Literacy

The Takeaways

Five Practices Takeaways

  • Talk: Have people on hand whose job it is to onboard new people and help them through the beginning parts of getting acquainted with and contributing to your project or company. Keep them around as troubleshooters for new learners as well, and make them available to bounce problems and ideas off of. As literacy and fluency increase in the learners, they'll start branching out and finding their places (and using rubber ducks to bounce problems off of), but they might come back at any time if there's a new aspect or language or other part they want or need to learn. Human guides and having someone to talk to (even if it's not synchronous) really helps a learner feel welcome and like they are making progress.

  • Sing: Good memory aids are always welcome. Distribute them widely. Sing the praises of good code, and especially good code from learners and beginners. Be willing to admit when things go sideways, and admit that things go sideways even for the most experienced programmers ever. And, y'know, sing. Out loud. Whether where anyone can hear you or not, because if what you are doing is something that squashes the instinct to sing (it doesn't have to be a nice song, by the way - Kill The Wabbit is perfectly acceptable), then things have gone seriously wrong.

  • Read: Read lots. Preferably documented, non-obfuscated materials that explains itself and offers visual aids where appropriate. Read style guides and optimization techniques, specifications and pull requests, and the documents on how to document your own work. Find a friendly person and read over their shoulder as they do tasks and accomplish objectives. If it makes sense, listen to audio or have someone else read to you while you learn to recognize the language and make the connections between the sounds and the squiggles.

    Once you have a feel for the rules, read things that bend them or outright break them and still manage to work. Figure out why. Understand why "ghoti" has the same pronunciation as "fish" in English. Keep reading.

  • Write: Write somewhere close to as much as you read, if possible. Do things that work. Do things that should work but don't. By accident, you'll likely do something that shouldn't work but does. (Figure out why.) Do ugly, clunky, and functional things, and then find ways of refining them into beautiful, sleek, and occasionally buggy things.

    Write tests. Do things designed to break tests. Do things designed to break systems. Do things designed to repair the damage and make those systems better than they were.

    Above all, make sure the documentation gets written. If not by you, by someone. Complete documentation is necessary for everyone, including you a few months in the future, to understand what happened.

  • Play: Let curiosity guide you. Make things into games, if they look like they'd be fun to do so. Any time you wonder a thing, write it down. Ask it if you can, when you have the opportunity, but if not, investigate it yourself. Take your 20% time to build your own interests and knowledge, and to have fun with the things that you want to have fun with. Talk to your rubber duck around other people. Follow the impulse that says "what would happen if...?" Do things that help ease your pain points, and then release your solutions into the wild for others. (Whether for-profit or not.)